Configuration Management
25.1 Version management 
25.2 System building 
25.3 Change management 
25.4 Release management

Software systems are constantly changing during development and use. Bugs are discovered and have to be fixed. System requirements change, and you have to implement these changes in a new version of the system. New versions of hardware and system platforms are released, and you have to adapt your systems to work with them. Competitors introduce new features in their system that you have to match. As changes are made to the software, a new version of a system is created. Most systems, therefore, can be thought of as a set of versions, each of which may have to be maintained and managed.

Configuration management (CM) is concerned with the policies, processes, and tools for managing changing software systems (Aiello and Sachs 2011). You need to manage evolving systems because it is easy to lose track of what changes and component versions have been incorporated into each system version. Versions implement proposals for change, corrections of faults, and adaptations for different hardware and operating systems. Several versions may be under development and in use at the same time. If you don’t have effective configuration management procedures in place, you may waste effort modifying the wrong version of a system, delivering the wrong version of a system to customers, or forgetting where the software source code for a particular version of the system or component is stored

Agile development, where components and systems are changed several times a day, is impossible without using CM tools. The definitive versions of components are held in a shared project repository, and developers copy them into their own workspace. They make changes to the code and then use system-building tools to create a new system on their own computer for testing. Once they are happy with the changes made, they return the modified components to the project repository. This makes the modified components available to other team members

For large systems, there is never just one “working” version of a system; there are always several versions of the system at different stages of development.
Configuration Management

25.1 Version management 
	Multiple parts, each with a different version
25.2 System building 
	Make (compile anew version of the system)
25.3 Change management 
	Requested changes
25.4 Release management
	How to get new versions to clients

Development, testing, release
Minor fixes, major fixes, new release
Some people shut off updates
Some keep old versions deliberately
(I never used windows 7)

Can have multiple versions created from one release
(might have to merge different versions back together in preparation for a new release)
25.1 Version management 
	Centralized versus distributed
	Knowing and tracking what changes
	Simple: increment a counter for each change
	Often have multiple versions out there
	Can be customized
	Users often do not upgrade
	Change history recording
	Storage management
	Project repository

25.2 System building 
	Different people working on different aspects
	Each updates
	Revise each version til it works
	Someone else has probably changed the system
	
	Automated tools for system build/make
		Individual parts may need particular versions
		Minimal recompilation
		Automatic tools for retesting
	Cannot always do everything on one system
		Target environment may not support development
		Development environment may not match target
		(virtual machines)
		Build server
		Modification time stamps
		Source code check sums
25.3 Change management 
	Deciding what changes to make
	Change request
		Bug report
		New requirement or capability
	Check validity
		Already bug
		New bug
		Misunderstanding
		Ignorant of feature
		Cannot replicate
		Change needs to be made
	Evaluate
		Estimate cost (to make change)
		Estimate cost (of NOT making the change)
		[or benefit in making the change]
		Number of users affected
		Consider product release cycle
			Should this be incorporated in the next version?
		Cost benefit analysis
25.4 Release management
	Major release (announce and charge money)
	Minor release (usually free)
	Release may contain:
		Configuration
		Data files needed
		Installation program
		Documentation
		Packaging and publicity
	Create a release
		Grab executable, data tag, release number
		Configure for different HW/OS
		Update instructions
		Scripts to install
		Web pages to advertise release and FAQ
		Executable master image created
			And prepared to distribute

Each system has different components, which may have different versions.
Each new release of a system is different, but people may still have the old system.
Clients may wish different (customized) versions of a system.
Clients may have different hardware, requiring different versions.
Clients may have different operating systems, requiring different versions.
Remember that the hardware, operating system and any other software or provider you interact with, could update at any time.
A new release cannot always assume the previous release is fully installed.